Personal computers (e.g. IBM.TM. PCs, ISA, EISA or Macintosh.TM. systems or the like) may be provided with provisions for adding devices to the computer system. For example, an ISA (Industry Standards Association) type personal computer (PC) may be provided with so-called expansion slots coupled to the system bus for receiving device "cards" which plug into such expansion slots. Other types of expansion techniques may also be used, such as a PCMCIA (Personal Computer Memory Card Interface Association) slot, SCSI (Small Computer Serial Interface) port or the like. In addition, devices may be interfaced with a personal computer using existing I/O ports such as serial or parallel ports.
Examples of devices which may be added to a computer through expansion slots or the like include modems, network cards, add-on memory cards, multimedia cards, sound cards (e.g., Soundblaster.TM. card or the like), hard drive and/or floppy drive controllers, I/O devices or the like. A device may comprise one or more logical devices, each of which may be assigned system resources such as an I/O address, interrupt level, and DMA channel. Devices may also be provided on the PC system motherboard, such as internal memory, keyboard controller, hard and floppy drive controller, video controller, or the like, and may also be assigned I/O addresses, interrupt levels, and DMA channels. For the purposes of this application, the term "device" shall refer to such add on or internal devices for a PC.
An I/O address may be an address location (e.g., hexadecimal) which a device uses on a system bus to determine whether or not a particular CPU cycle is designated for that device. The I/O address may generally be a sixteen bit address within the first 64K of memory for an ISA type PC. A DMA channel is a channel (e.g., 0-7) between a device and a DMA controller in a computer system used in order to obtain direct memory access (DMA) services from the DMA controller. The interrupt (IRQ) level is used as a priority level to get the attention of a host CPU. Different devices within a computer system may have different interrupt priority levels. If two or more interrupts are received simultaneously, a host PC can prioritize which interrupt request to honor (and in which order) by priority level.
In the prior art, such I/O addresses, interrupt levels, and DMA channels may be predetermined according to an industry standard. For example, in an ISA type PC, I/O addresses, interrupt levels, and DMA channels for I/O ports (e.g., COM1, COM2, LPT1, LPT2 or the like) may be predetermined and preassigned according to an industry standard. Similarly, I/O addresses, interrupt levels, and DMA channels for other devices may be similarly predetermined and preconfigured. Thus, if a user installs an expansion device (e.g., modem) into an ISA type PC, software operating within the ISA type PC will expect the expansion device to operate according to predetermined parameters (i.e., I/O address, interrupt level, and DMA channel). Thus, for example, for a modem installed as an expansion device, software operating within an ISA type PC may expect I/O access at a particular address and DMA accesses through a particular channel.
Prior art PC expansion techniques, however, have some disadvantages. For example, since a device may have a particular predetermined I/O address, interrupt level, and/or DMA channel, it may be difficult to install a number of such devices within one PC without a conflict arising between I/O addresses, interrupt levels, and DMA channels of different devices. For example, a network card may be incompatible with a fax/modem card, as both devices may expect to use the same I/O address, interrupt level, and/or DMA channel. Thus, a user may have to select one card over another or reconfigure the PC.
FIG. 1 illustrates the sequence of steps occurring on power up in a prior art ISA type PC. In step 100, power is applied to the PC. In step 102, each ISA compatible device is powered up, with fixed I/O address, interrupt (IRQ) levels, DMA channels, and other assignment of system resources. In step 104, software from the ROM BIOS (i.e., so-called firmware) in the PC is executed and the PC then boots from a boot device (e.g., hard drive). For the sake of illustration, the POST (Power on Self Test), which generally occurs before the software in the ROM BIOS is executed, is not shown in step 104. In step 106, an operating system is then loaded from the boot device and executed. As can be seen from FIG. 1, I/O addresses, interrupt levels, and DMA channels are fixed by hardware and generally may not be changed.
It may be possible to reconfigure a PC or a device to overcome such a problem. For example, software may be provided with an expansion device to reconfigure the PC after power up to alter the predetermined I/O addresses, interrupt levels, and DMA channels. A user may install such software in a PC to operate upon power-up or reset (e.g., as an AUTOEXEC.BAT file or as a device driver in a CONFIG.SYS file) to reconfigure default I/O addresses, interrupt levels, and/or DMA channels in the ROM BIOS of a PC. Alternately, the device may be altered by use of jumper blocks, DIP switches, or the like, to reconfigure the device to use a different I/O address, interrupt level, and/or DMA channel.
While such reconfiguration techniques may be feasible, they may present additional difficulties and inherent limitations. For example, many users may be unfamiliar with the basic operation of a PC and thus may require assistance to install reconfiguration software. Further, such software adds additional cost to a device. Users unfamiliar or uncomfortable with the use of electronics may have difficulty setting jumpers, DIP switches and the like. Such jumpers, DIP switches, and the like add additional cost to a device.
Moreover, such reconfiguration techniques may still only allow for a limited number of devices to be configured within one PC. For special applications, a user may wish to add a number of similar of dissimilar devices to a PC. For example, to make copies of software, a user may wish to add a large number of floppy disc driver controllers to one PC to drive a large number of floppy disc drives. Similarly, a user may wish to add a large number of PCMCIA host card adapters to store data to PCMCIA memory cards.
Recently, a new technique for configuring a computer system has been proposed known as a Plug and Play (PNP) system. A preliminary specification has been proposed for such a PNP system for use in ISA type PCs. This specification, entitled, "Plug and Play ISA Specification, Version 1.0a" dated May 5, 1994, is incorporated herein by reference. For the purposes of this application, a computer system (e.g., ISA type PC) supporting the PNP specification and protocols may be referred to as a PNP type system or PNP type PC.
In a first kind of PNP type system, software stored in a PCs ROM BIOS may configure a system after power up to assign I/O addresses, interrupt levels, and DMA channels to each device in a system. Devices built according to the PNP specification may operate in conjunction with software provided in the ROM BIOS. FIG. 2 illustrates the steps in the process of configuring this first type of PNP type system using firmware (i.e., ROM BIOS).
In step 100, power is applied to a PC. In step 113, PNP devices required for system boot may become active on power up using power-up default I/O addresses, interrupt levels, and DMA channels. Examples of devices required for system boot may include hard and floppy disc drive controllers, keyboard controllers, display controllers (e.g., VGA controller) or the like. For a system booting off a network (e.g., Novell.TM. type network) a network card may be considered a device required for system boot. Default I/O addresses, interrupt levels, and DMA channels may be preassigned and may be those addresses used under the current ISA (i.e., non-PNP) standard or traditional industry addresses.
PNP devices not required for system boot may power up in an inactive state. Examples of PNP devices not required for system boot may include modems, parallel or serial I/O ports, sound cards, or the like. Such devices may not be required for system boot and initial loading of operating system and the like.
What is considered a device required or not required for system boot may depend upon the configuration of the system (e.g., network boot versus hard drive or floppy drive boot). It should be noted that whether a device is required for system boot may be preconfigured within a PNP device. Thus, for example, a PNP hard drive controller may be preconfigured as a device required for system boot. For a PNP type system booting off a network servel, a network card may be preconfigured as a PNP device required for system boot. Such configuration may be hard wired into the device (e.g., hard drive controller, floppy drive controller) or may be selectable using jumpers, DIP switches or the like (e.g., network card).
In step 114, the program in ROM BIOS may isolate each PNP device, assign a "handle" (number) to each card, and read the resource data from that card. Once each card had been isolated, assigned a handle and read, the software in ROM BIOS will check for conflict in the devices required for boot, and activate each boot device. Optionally, at this time, the software in the ROM BIOS may configure other devices within the PC, or leave them in an inactive state. The PC may then boot, for example, from a hard drive and load and execute an operating system (e.g., MS-DOS.TM., O/S-2.TM., WINDOWS.TM., UNIX.TM. or the like).
In step 126, the operating system may then retrieve PNP information from the ROM BIOS, read resource data from all devices, and arbitrate system resources for all PNP devices. Conflict-free resources may then be assigned for all inactive devices and the devices activated. Finally, appropriate device drivers may be loaded and the system is thus configured.
The system of FIG. 2 may be used in new ISA type PCs to provide PNP compatibility. However, there is already a large installed base of older ISA type PCs throughout the world (e.g., PCs built around the Intel.TM. 8086, 8088, 80186, 80286, 80386, 80486, or Pentium.TM. microprocessors, ADM.TM. 386 and 486 processors, or PowerPC.TM. processors). For the purposes of this application, such non-PNP systems may be referred to as legacy PCs. It may be possible to upgrade a legacy PC by installing a new ROM BIOS. However, such a technique may be expensive and difficult to implement, particularly if the ROM BIOS is not provided on a separate, removable chip.
To overcome this difficulty, operating systems employing PNP technology have been proposed. For example, the proposed Windows 95.TM. operating system (formerly Windows.TM. Chicago) may incorporate such PNP software to support the PNP standard. Alternately, or in addition, DOS, O/S-2.TM., or UNIX.TM. operating systems may be upgraded to support the PNP standard.
FIG. 3 illustrates the steps in powering up a computer using a PNP compatible operating system. Such an operating system may be retrofit to a legacy PC. In step 100, power is applied to a PC. In step 113, PNP devices required for system boot become active on power up using power up default I/O addresses, interrupt levels, and DMA channels. PNP devices not required for system boot are inactive on power up.
In step 104 the program on the ROM BIOS of the PC may be executed and the PC will boot from its boot device (e.g., hard drive, floppy drive, network card, or the like). In step 116, the operating system may be loaded. The operating system software may be provided with support for PNP devices. In a similar manner to the ROM BIOS software of FIG. 2, the operating system will isolate each PNP device, assign a "handle" (number) to each card, and read the resource data from that card. Once each card had been isolated, assigned a handle and read, the operating system software will arbitrate system resources for all PNP devices. Conflict-free resources may then be assigned and the devices activated. Finally, appropriate device drivers may be loaded and the system is thus configured.
Applications software accessing a device then receives from the operating system software the address locations for that device. Thus, for example, a modem card using PNP technology may be assigned system resources by a PNP compatible operating system according to the PNP protocol. Applications software (e.g., communications program or the like) may then communicate with the operating system to determine the address locations of the modem card in order to communicate with the device.
The system of FIG. 3 has the advantage in that it may be more readily implemented in legacy PCs by upgrading the operating system (e.g., Windows.TM. or DOS) to an operating system supporting PNP technology. However, a user may not wish to upgrade his operating system merely to provide software support for a PNP device. For example, a legacy user who wishes to install a new sound card, CD-ROM controller or the like may not wish to go through the expense and effort of installing a new operating system merely to provide compatibility for a PNP type device.
Such a user may instead wish to purchase a non-PNP type device. As a result, a manufacturer of a device may lose market share unless a given device is offered in both PNP and non-PNP compatible configurations or is provided with an internal jumper, DIP switch or the like to disable PNP modes of operation. The former approach may be costly in terms of manufacturing and inventory expense and may delay widespread use of PNP technology. The latter approach, providing a DIP switch or the like, defeats the fundamental precept of PNP technology--namely to allow a user to "plug" in a new device without such configuration steps.
Moreover, it may be possible that existing applications software may not be compatible with an operating system supporting the PNP standard. For example, a communications program may be configured to send and receive data from one of a number of predetermined I/O addresses (e.g., COM1:, COM2:, or the like). If such I/O addresses are reassigned, an applications program not designed for the PNP standard may not be able to communicate with the device and thus not operate properly.
FIG. 4 illustrates a third embodiment for implementing PNP technology using applications software. In FIG. 4, steps 100, 102, 104 and 106 are executed in a similar manner to that shown in FIG. 1. However, once the operating system is executed, an application program may then be executed to provide PNP support in step 146.
Such an applications programs may be executed after boot (e.g., AUTOEXEC.BAT or WINDOWS.INI file) or configured as a device driver (e.g., CONFIG.SYS file). Alternately, such applications software may be provided within an applications program (e.g., communications program, word processing program, or the like). Once executed, the applications program isolates each PNP device, assigns a "handle" (number) to each card, and reads the resource data from that card. Once each card had been isolated, assigned a handle and read, the applications program software will arbitrate system resources for all PNP devices. Conflict-free resources may then be assigned and the devices activated. Finally, appropriate device drivers may be loaded and the system is thus configured.
Although the PNP systems of FIGS. 2-4 provide PNP compatibility, such techniques may be unsuitable or may be undesirable (e.g., to expensive or complicated to install) for legacy PCs. As a large number of legacy PCs exist throughout the world, a manufacturer of a PNP device may desire to make a PNP device which may be applied to both PNP and non-PNP systems. In order to install a PNP device, a legacy user may either install a new PNP compatible operating system (FIG. 3) or install PNP compatible applications software (FIG. 4). If a legacy user does not install such software, a PNP device not required for system boot may be inactive upon power up and may not be subsequently activated.
In order to overcome this disadvantage, a supplier of PNP devices may either package his PNP device with applications software (or operating system) supporting PNP devices, or provide his PNP device with hardware configuration device (e.g., DIP switch, jumper block or the like) to disable the PNP function when used in a legacy PC. However, either approach may defeat the purpose of PNP technology, namely to provide a device which may be installed by a user without the need for supplemental software installation or device configuration.
Further, such packaged software or hardware configuration device may add additional cost to a PNP device. Moreover, if applications software is provided for each PNP device, and a legacy user installs a number of PNP devices in a legacy system, PNP applications software from different manufacturers may itself be incompatible. Thus, prior art PNP devices may not provide true plug and play compatibility for legacy PC users.
Moreover, for a semiconductor manufacturer, providing such plug and play technology may be disadvantageous from a marketing standpoint. When manufacturing and marketing a semiconductor device (e.g., video controller IC, interface IC, or the like), a manufacturer may be required to provide such PNP application software to a customer (e.g., device or computer manufacturer). Customers may or may not require PNP support for their products, however, the alternative of offering separate PNP and non-PNP compatible IC products may increase manufacturing and inventory costs, cause unnecessary confusion, and delay implementation of PNP technology.